A video on demand (VOD) service relies on a network Internet Protocol (IP) infrastructure and is generally based on three main components.
The first component is the head end equipment which is the platform responsible for presenting the live content available to the user and may include managing the dynamic information coming from a broadcaster for an Electronic Programming Guide (EPG). The head end may also provide the administration services for the encoders/transcoders used to transmit the video streams to the users.
The second component is the middleware equipment which ensures the digital content delivery and provides the portal and services such as VOD that could be installed close to the Digital Subscriber Line Access Multiplexer (DSLAM), which is the component responsible for connecting the PSTN line to the IP Backbone of the provider. The user could use the middleware to provide certain video services.
The third component is the end-user equipment which includes the elements installed at the point at which the content is viewed by a user. This may include such elements such as a residential gateway (Modem), a Set Top Box (STB), an IP or Analogue phone and a PC. Video services may be provided in the STB or the PC or in some other way.
The combination of the three components is called the “triple play” model and could be relevant in different environments such as mobile phones, PDAs and car embedded devices.
A broadcast system such as that described above is based on a multicast mechanism (one to many connections) and uses the IP Group Multicast Protocol RFC1112 to manage the user requests. Users requesting the streaming of the same Video are brought together to become members of a unique IP Multicast group (IPMG).
On the other hand a Video on Demand service is based on a unicast mechanism (one to one connections) and uses the Real Time Streaming Protocol (RTSP) (see RFC 2326). When a user wants to view a video, a unicast peer to peer session is created between user equipment and a Video server. The means used to manage the interaction with the video such as “Pause”, “Fast backward”, “Fast forward” and “Play” is handled by the RTSP. A Unicast peer to peer session leads to a huge number of sessions which may be very expensive in terms of bandwidth and server charges but give greater user flexibility in terms of viewing capabilities and functions.
With respect to multicast broadcasts there are also some advantages and disadvantages. In a multicast session the users must all start the video streaming at the same time and the VCR functions described above (i.e. “Pause”, “Fast backward”, “Fast forward” and “Play”) are no longer available.
Real Time Streaming Protocol (RTSP) is an Internet Engineering Task Force (IETF) proposed standard for controlling streaming media (see RFC 2326). It describes a set of messages that enable the efficient delivery of streamed multimedia over Internet Protocol (IP) networks.
RTSP works with established protocols, such as the Real Time Transport Protocol (RTP—see RFC 1889) and Hypertext Transfer Protocol (HTTP), to provide an integrated approach to streaming media over the Internet.
In VOD service a user makes a request to a server to receive a media stream using VCR-style asset controls such as play, fast-forward, rewind and pause. To implement these actions, the server uses RTSP message pairs which consist of a user request and a server response. One user action can give rise to more than one Time streaming Protocol (TSP) message pair.
FIG. 1 shows the main types of message that may be used in the RTSP protocol.
A user requests a movie with the DESCRIBE and SETUP requests. The server responds with a DESCRIBE response and provides parameters related to the media, such as the audio header and duration. The SETUP message transmits transport parameters and establishes a session with a unique session ID. Once the movie is opened, the user can play it in normal, fast-forward, or rewind mode by sending a PLAY request with a Scale parameter that indicates the mode and speed. A PAUSE request may also be sent to pause the movie. Finally, a TEARDOWN request allows the user to exit from viewing the movie.
As previously indicated IP multicast provides an efficient one-to-many delivery service. To achieve such a delivery using IP unicast traffic, each datagram needs to be sent many times. To achieve one-to-many delivery using IP broadcast traffic, a single datagram is sent, but all nodes process it, even those that are not interested in it. Broadcast delivery service is unsuitable for inter-networks, as routers are designed to prevent the spread of broadcast traffic. With IP multicast, a single datagram is sent and forwarded across routers only to the network segments containing nodes that are interested in receiving it.
Historically, IP multicast traffic has been little utilized. However, recent developments in audio and video teleconferencing, distance learning, and data transfer to a large number of hosts have made IP multicast traffic more important.
The following describes the main details of IP multicast operations.
All multicast traffic is sent to a class D address in the range 224.0.0.0 through 239.255.255.255 (224.0.0.0/4). All traffic in the range 224.0.0.0 through 224.0.0.255 (224.0.0.0/24) is for the local subnet and is not forwarded by routers. Multicast-enabled routers forward multicast traffic in the range 224.0.1.0 through 239.255.255.255 with an appropriate Time to Live (TTL). A specific multicast address is called a group address.
The set of hosts that wish to receive multicast traffic at a specific group address is called a multicast group or host group. Multicast group members can receive traffic at their unicast address and the group address. Multicast groups can be permanent or transient. A permanent group is assigned a well-known group address. An example of a permanent group is the all-hosts multicast group, awaiting traffic on the well-known multicast address of 224.0.0.1. The membership of a permanent group is transient, only the group address is permanent.
There are no limits on the size of a multicast group. A host can send multicast traffic to the group address without belonging to the multicast group. There are no limits to how many multicast groups a host can belong to. There are no limits on when members of a multicast group can join and leave a multicast group. There are no limits on the location of multicast group members. IP multicast must be supported by the hosts and the routers of an IP inter-network.
IGMP is used by IP hosts to report group memberships to any neighbouring routers that are multicast enabled. IGMP is implemented in the IP module as shown if FIG. 2A. IGMP messages are generally encapsulated in IP datagrams.
An IGMP v2 message consists of 64 bits, and contains the type of the message, a maximum response time (used only for membership queries), a checksum, and the group address as is shown in FIG. 2B.
The message types used for communication between a host and a router are defined by the first 8 bits of IGMP v2 message headers, and are shown in FIG. 2C.
In all VOD services the best utilisation of bandwidth is a permanent quest. Also it is a fact that there are surges and troughs in the bandwidth requirements of users. For example at certain times of the day or for certain events demand will be high.
It is now possible to record TV live (TSTV) and watch the same later at a time which suits the user. This is sometimes referred to as the NPVR (network personal video recorder) function. This solution is based on VOD technology in which a channel is recorded and then each user forms connects via a unicast connection to the server to watch the recorded channels. For a live football match several million users may want to watch. Also if a goal is scored or a good save is made many viewers may simultaneously wish to replay sections of the match. This requires a very high demand for bandwidth at those times. Current systems are simply unable to handle the demand and thus replay can not be offered as a service by most providers. If any service of this type is provided there are often severe restrictions, costs or delays.
As indicated a TSTV service is one in which a viewer watches a program at a time which the user chooses. For example, the user may wish to watch a certain program but is not going to be in at the scheduled time for the broadcast of that program. Thus the user has the program recorded and stored at either the service provider end or the user end. When the user is ready to watch the program the stored program is replayed on demand. It will thus be appreciated that the manner in which TSTV is provided to the user is essentially identical to the manner in which VOD is provided to the user. Accordingly reference to VOD and TVTS in terms of the function of the present invention are essentially interchangeable and are intended to be construed thus.